Organization Hierarchy

Organization Hierarchies can be setup to emulate your company's structure. This becomes especially important if you plan on using any of the Approval Rules features.

Is it necessary to define an organization hierarchy?

No it is not necessary. If there are only a small number of users, it's probably not needed.

When should a company hierarchy be used?

Does your company require an approval process for Orders or Content? If the answer is yes, then you should setup a hierarchy.

Sample hierarchy

Below is a sample company structure containing both Organization Levels and Organization Nodes.

Organization Levels

The Organization levels are the horizontal bands (Company, Region, Branch, Office, Agent).

Organization Nodes

Each of the blue boxes represents a single Organization Node at a specific organization level.
The lines connecting each Organization Node represent the relationship between parent and child (top down).

In the example above, we see the following:

• Agent 47 is an Organization Node that reports into Office 982.
• Office 982 reports up into the "Connecticut" branch
• The "Connecticut" branch reports up into the "US Northeast" region.
• The "US Northeast" region reports up into the Company.

Organization Nodes Verses Users

Looking at the sample setup above, it's easy to fall into the trap of assuming than an Organization Node is the same as a user.

Example:

One way to look at this is to think of Organization Nodes as positions within your organization.

Let's say we recently opened "Office 982" in the "Connecticut" Branch.

We have positions that needed to be filled in this new Office. So we hire Jane Doe to fill the position and associate her with the "Agent 47" Organization node.

In doing so we establish Jane's reporting structure within the company. Orders she places will go through the appropriate approval processes as defined by the Organization Structure.

Now let's say 2 years pass and Jane Doe has left Office 982. We need to replace her as she was playing a vital role, so we hire John Doe.

We then associate John Doe with the "Agent 47" organization node because he will have the same reporting structure as Jane Doe did.

You may be asking yourself, "won't there be confusion when John Doe logs in and sees Jane Doe's Orders?"

The answer is no. Remember, if we think of the Organization Node as a position, a position remains the same, but people come and go to fill that position. Orders and all related items that belonged to Jane Doe do not get magically transferred to John Doe when he logs in.

The only thing that carries over is the reporting structure.

Of course, if your organization is more comfortable simply creating a new position (Organization Node) for new individuals, you can certainly take this approach as well.

Affiliation vs Authority

It's important to understand the distinction between a user being associated with an Organization Node and a user having authority over an Organization Node.

This distinction plays a key role with Approval Rules.

Example:

Let's continue using the example above.

We left off with John Doe being associated with the "Agent 47" Organization Node.

This means that orders he creates go up through the approval process in "office 982".

Now let's say over time, you discover that John Doe grew up in Germany, is fluent in German and has proven to be a worthy employee.

Meanwhile you've noticed over time that the "Germany" branch has repeatedly shown signs of trouble when placing orders or submitting content for approval.

You decided that in addition to his responsibilities in Office 982, you would like John to help out the Germany branch in their approval process.

To accomplish this, we must:

Grant "John Doe" authority over the "German" Organization node at the branch level.

This means that orders placed by John's counterpart in the "Germany" branch, John will now be able to approve.

All the while ensuring that orders he places in his own branch will continue to go through the established approval hierarchy.

Conclusion

We see here that 'authority', as the name implies, gives the user the ability to approve items at other branches. Where as the association dictates how items John submits abide by the hierarchy.

This can get pretty complicated, but such complex structures are sometimes necessary in a large organization and need to be created.